-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--get "{query:$NAME}"
only returns the first match
#302
Comments
Agreed. Should it require a different option? How should it provide them in the output? |
Given that parsing the output of So this could look like this:
There are risks attached to this if the value contains characters like line breaks and tabs due them getting URL-decoded by default:
This can be circumvented by keeping the URL-encoding in place:
|
|
But yeah, when the output can be "anything", making separators becomes difficult. |
I suppose one way could be to allow trurl to mention how many instances there are, as then a user could cherry-pick the exact instance. For example: (brain-storming mode engaged)
|
From a shell-user perspective I'd personally prefer a GREPable output format. The counting and index features would require loops while something like a tab-separated list does not. In the case of a GREPable output format one could just string the |
How would a tab in the content be separated from the tab as a separator? |
Ah, we do have:
|
(Which has the separator problem but with space..) |
It wouldn't in a secure way just like it currently isn't securely possible in this case:
But with keeping the URL-encoding in place, this is not an issue:
Ah, I must have overlooked that in the manpage.
Which is equivalent to the thing mentioned above. Keeping the URL-encoding in place during the parsing stage solves the separator problem:
|
Maybe we should offer the user a way to specify the separator as a custom string, as then a user can increase the chances of it working... |
As |
I personally don't think that will help a lot with handling query parameters in a secure way. Users already have the option to replace the separator with something of their liking via A safe way for users to handle separators e.g. looks like this:
That's even the case with
|
If you set the separator to be for example 16 random letters, the risk they will be in the content is next to zero. But of course then the user needs to split the content into separate parts using the same boundary. Which admittedly is inconvenient. It could be made to work like this:
Keeping the content URL encoded is another way and one that already is there, but then the user still needs to decode the data in a second inconvenient step. |
I think that since this feature is actually already supported we can just call this solved. We can of course most certainly still improve the option to become more "intuitive" and easy to find in -h output and manpage etc. |
I learned about
trurl
today and gave it go. You can get the value of a query parameter through--get "{query:$NAME}"
. It's also possible to add multiple query parameters with the same name through--append "query=$NAME=$VALUE1" --append "query=$NAME=$VALUE2"
. However,--get "{query:$NAME}"
will only retrieve the first value.This might lead to lost information. Some implementations (like PHP) support multiple values for a query parameter (like
$NAME[]=$VALUE1&$NAME[]=$VALUE2
). Some implementations (like PHP if the query name does not end in[]
) use the last occurrence of a query parameter instead of the first.It would be great to have a way to get all values of a specific query parameter name returned.
The text was updated successfully, but these errors were encountered: